The use of cryptography for purposes of data security is increasingly prevalent and critical to communication and commerce over networks that include computer communications networks, satellite data links, and PBX and ISDN telephony links of various kinds. Generally speaking, cryptography is based on cryptographic keys, which may be referred to herein as “C_Keys”. In the description that follows, the term “enveloping” may be used to denote encryption, while the phrase “opening an envelope” may refer to decryption using a cryptographic key. Whenever one or more keys are stored (or otherwise available), there is a need for deciding, in each instance, what key is to be made available for a particular purpose. Thus, it might be desirable to make distinct keys available to distinct users, or, alternatively, to a distinct class of users for a specified purpose. The decision regarding which key, if any, is to be made available in a particular case is currently performed in a non-automated way.
Cryptographic keys may include both symmetric and asymmetric keys. Symmetric keys must always be kept only within a restricted group of users, because if a message is encrypted with a symmetric key K1 then anyone knowing K1 can decrypt that message.
For the case of asymmetric keys, at least one pair of keys is associated with each owner. One key of each pair of keys is private (known and kept only by its owner). The other key is public (i.e., it is distributed freely to the public). A message encrypted with one of the keys of the pair can be decrypted only with the other key in the pair. In addition, a message may be cryptographically signed with one of the keys in the pair and the second key in the pair may then be used to verify the authenticity of the specific message.
As used in the present description and in any appended claims, the terms “owner” and “user” are not restricted to humans but may equally encompass machines or programs, or, for that matter, multiple tasks and devices. In the following, the names “Alice” and “Bob” are used as examples.
For purposes of providing a concrete, though not limiting, example of the use of asymmetric cryptography, it will be assumed that Alice intends to send to Bob some secure message.                1. Bob must have a pair of keys and Alice must know Bob's public key;        2. Alice must have a pair of keys and Bob must know Alice's public key;        3. Alice generates a SYMMETRIC key which she uses to envelope her message to Bob, and uses Bob's public key to envelope the symmetric key, and sends both envelopes to Bob; and        4. Bob will open the envelope using Bob's private key to fetch the symmetric key sent by Alice and then use the symmetric key to fetch the message.        
For conveying a signature, Alice uses a hashing function to generate a digest (D) of the message and signs the digest using Alice's private key producing SD. Bob then opens SD using Alice's public key, thus recuperating D. Subsequent to retrieving the message received from Alice, Bob produces a digest (D1) of the message using the same hashing function that Alice used. Only in the case D and D1 are identical Bob may assume that Alice signed the message that Bob received from Alice.
Bob's postings to Alice undergo the same procedure but with “Alice” and “Bob” exchanged.
In order to accomplish the transmission described above, Alice and Bob must exchange their respective public keys in such a way that each of them knows at a satisfactory level of confidence that the key received really belongs to the real user. This is referred to as an “authentication problem,” and is addressed by authentication centers. Such a center—usually referred to as a Certificate Authority (CA)—delivers certificates by means of a Certificate Server (CS). A certificate confirms some linkage between data elements, which may include, without limitation, a name (or any other identifier) and a public key. Typical elements of a certificate are those depicted in the schematic representation of a prior art certificate shown in FIG. 1. It is assumed that the public key of some CA is well known. Hence if Alice asks for Bob's certificate and such a certificate has been released by a particular CA, referred to as CA_X, then Alice might check the validity of the certificate and its contents (including it's being related to Bob and usually holding Bob's public key) by using the public key of CA_X (which is assumed to be known to Alice directly or by other well-known tracing means).
For purposes of the present description, and in any appended claim, the term “cryptographic key” will, as a matter of definition, be understood to refer, as well, to certificates that contain keys. Similarly, the term “certificate” will refer, as well, to keys contained within them. Finally, again as a matter of definition, the term “certificate authority” will be understood to include one or more certificate servers, whether or not pertaining to a single certificate authority.
Some user might have a number of certificates. The certificates of a user might reside on one or more certificate servers. Reasons for maintaining multiple certificates per user include, for example, separating C_Keys at home from those used at the work place, so that access by an employer, for example, does not compromise the security of the documents not related to the workplace. Another reason might be that distinct applications may use different protocols with different cryptographic schemes or different forms of data representation.
Referring again to the hypothetical example, in light of a plurality of potentially available certificates, if Alice is interested in fetching one of Bob's certificates (which may reside on one or more Cerificate Servers), and the CS has a number of certificates for Bob, then the CS might randomly offer to Alice one of them, all of them or none, unless Alice supplies a more precise definition that points uniquely to some specific certificate.
More particularly, Bob might have a unique identifier, referred to as Bob_UID, as well as a multiplicity of certificates located at some CS. The arrangement of stored certificates is shown schematically in FIG. 2. When Alice asks for Bob_UID, the CS has no means to know which certificate to deliver to Alice since Bob_UID points to all certificates owned by Bob.
Similarly, if Alice maintains public key counterparts of a multiplicity of keys belonging to Bob (referred to as Bob—1, Bob—2 . . . Bob_N, each unique}, then Alice has to decide each time which one of Bob's public key to use in a particular situation. The storage of data including Bob's certificates in Alice's database is depicted schematically in FIG. 3, illustrating the ambiguity of a reference to Bob_UID. Furthermore, since Alice might wish to use a particular key of Bob's for a particular task and since there are a number of public keys in Alice's database, Alice is currently required to perform many individual non-automated steps.
Owing to the spreading prevalence of C_Key systems in the various contexts discussed above, and more particularly to the absence of well-defined relationships among technologies, protocols, certificates, etc., a method for automated C_key management and administration is desirable.
It is well known that the core of secured communications is trust. Trust is non-tangible—one cannot physically point to trust, see or show its image. Trust is non-transferable. If Alice trusts Bob and Bob claims something about Charley then perhaps Alice believes that what Bob says about Charley is true, but this does not imply that Alice would trust what Charley may say about itself or anyone else. Trust is relative and thus bounded. If Alice trusts Bob this does not imply that Alice would take for granted ALL that Bob says; or that Alice would authorize Bob to do all and everything on Alice's behalf and/or with assets controlled by Alice. Alice may trust Bob for some purposes and at some extent. While the situation of Alice not trusting Bob is very clear, Alice trusting Bob implies to clearly define the span of such trust (“for what”) and its degree (“how much”).
Between a Certificate Authority (CA) and a Deployment Site (DS) there must be a relation of trust. If DS desires a CA to grant a certificate on behalf of the DS (i.e., DS wants CA to certify that DS is who he claims to be), then:                DS must trust the CA for the purpose of having the certificate released        CA must trust DS for the data that the CA is about to certify regarding DS        
Such situation is represented by FIG. 4—The ID Equation. Between CA (101) and DC (102) a trust relationship (103) must be established. Such relationship is based on the principles of the circle of identification and authentication. Each side has to identify the other side and authenticate the means leading to such identification. Once the circle is closed, CA will release a certificate to DS. This process is similar to the process through which an individual obtains a passport from his/her country. It is obvious that the degree of authentication and identification is bounded. As an example, for some purposes DS may need to be identified by its absolute identity such as its registered name with the State or its social security number. For other purposes CA may need to identify DS by a non absolute identity such as a pseudo-name (e.g. DS nick name, DS e-mail address). Obviously the degree of identification will impact the degree of trust DS might gain from a counterpart receiving such certificate granted by CA.
For the purpose of example let be assumed that DS Alice gains a certificate from CA. Alice presents to Bob such certificate, Alice's immediate goal being to convince Bob that Alice is the legitimate holder of the certificate. To do so Bob conducts a process of authentication and identification as described in FIG. 5 {DWG2}. First Bob must trust the CA (201) for the purpose of authenticating Alice's identity. If Bob does not trust the CA, then the certificate has no value in the context of Alice's immediate goal. If Bob trusts the CA then Bob authenticates the certificate (202). That is, Bob makes sure that the certificate is from CA and it is valid. For this purpose Bob checks the certificate and the CA signature on the certificate by means of the public key of the CA; and makes sure certificate validity time did not expire; and makes sure the certificate is not included in the Certificate Revocation List (CRL) of CA. Third Bob identifies the subject (203) being Alice by some means like biometric data or electronic signature (challenging message) from Alice. Forth, if phases 201–203 are successful, then Bob trust Alice at least to the extent of what the certificate states but not necessarily beyond that. For example, if the certificate certifies Alice's name, then Bob trusts that he is communicating with Alice, which enables Bob to trust the physical integrity, technical authenticity and signature of messages sent to him by Alice. Bob may also encrypt messages for Alice and trust that such messages are understandable only by Alice, thus allowing privacy of the messages sent by Bob to Alice. However, having Alice identified by Bob does not imply that Bob trusts the intrinsic contents (e.g. expressed ideas) included in messages he receives from Alice. For example, even when Bob believes that Alice is who she claims he would not necessarily trust Alice claiming she acts on behalf of Charley, unless Alice can present to Bob some proof for that. Obviously here a new need for trust occurs, since Bob has to trust the authenticity of the proof and the fact that Charley empowered Alice to act on his behalf. It is a matter of Alice being granted some privileges by Charley, Bob trusting that Charley granted the said privileges to Alice and then eventually Bob may facilitate Alice to take advantage of such privileges.
Under some circumstances a certificate may contain privileges. Alternately, privileges may be stated in a separate authorization bounded to one or more certificates. The holder of such authorization has a non-empty set of privileges. For example, a visa is a privilege granted to its holder to enter the country that released the said visa. But the visa is useless unless its holder can be identified by his or her authenticated passport, which must be thought valid and granted by a trusted representative of a legitimate State. In other situations an authorization does not require to identify the holder in an absolute manner, such as his/her real name. For example, a phone card authorizes the holder to make phone calls from a public phone of some company. While there is need to authenticate and identify the phone card grantor, the card and the phone in which the card is inserted there is no need to identify the holder of the card.
In the world of electronic communications, which by nature is borderless, the reality is extremely complex as represented in FIG. 6. The Set of Mind (301), which is of a human nature, impacts Trust (301-a). There always is a set of Rules (302) of behavior without which ordered society cannot exist. The set of rules encompasses Laws (302-a)—imposed by Counties, States or other forms of socio-political orderliness—and Procedures (302-b) that are established by a local organization such as workplace. Trust, laws and procedures integrate into Policies (303). Policies (303) and technologies (304) integrate into Solutions (305). Solutions are what finally count for secured data and secured communications in real life.
In the past several attempts to create centralized or quasi-decentralized mechanisms of managing certificates and keys on the grounds of centrally approved policies were made. The intention was to impose methods enabling digital certification. These attempts failed. Privacy Enhanced Mail is one example of such failure. Multilevel Information Systems Security Initiative (MISSI) is an additional example for such an attempt that resulted in failure. It was proven that it is impossible to impose a uniform centralized model of policies (and solutions) for digital certification and use of such certification. Society recognizes the need for replacing compulsory approach with collaboration and agreement on the security deployed by the sides in a transaction and/or a communication session. Public Law 106- 229 represents such an effort. While this statute deals with validity of electronic records and signatures for e-commerce, it does not teach any practical way of doing so in the solution sense. It only recognizes the need for such solutions and lays the legal grounds on which the solutions may relay. A similar need is also suggested by General Directive 95/46 of the European Community. Moreover Directive 95/46 emphasizes the rights for privacy and sets a serious challenge of coping with the variety of laws relevant to electronic transactions, data communication and data storage in the European Community (EC) as well as worldwide from the standpoint of EC. Overall it is obvious that the world community recognizes on one hand the need for data and communication security while on the other hand the community leaves to the parties to decide by agreement and within the legal frame appertaining to different places what kind of security solution should be deployed.
Public Key Infrastructure (PKI) known as of now is restricted to X.509 certificates. PKI is segmented since the PKI concept is tied to isolated CAs. Attempting to bridge over this segmentation, some CAs conduct a process of cross-certification. But cross-certification, despite its aim, does not solve the problem of trust—since as already mentioned trust is non-transferable. For example Alice trusts CA1 and CA1 cross certifies CA2. Alice might authenticate a certificate from CA1 and identify CA2 through the certificate granted by CA1 to CA2. Alice may validate in the technical sense a certificate granted by CA2 to Bob. Yet Alice will not implicitly trust the contents of a certificate granted by CA2 to Bob (she may doubt that truthfulness of the contents of such certificate). It is clear that if Alice trusts CA2 then CA2 does not need a cross certificate from CA1; and if Alice does not trust CA2, having CA2 cross certified by CA1 is useless. Other means of managing and administering certificates and keys, such as Pretty Good Privacy (PGP), Simple Public Key Certificates (SPKI) and Simple Distributed Security Infrastructure (SDSI) use non X.509 formats of certificates and are based on heterogeneous technological as well as heterogeneous policy concepts. As a result of this situation, known art is unable to satisfy in an integrative manner the needs for solutions as represented in FIG. 6.